What is proper-lockfile?
The proper-lockfile npm package is used to create and manage file locks, ensuring that only one process can access a file at a time. This is particularly useful for preventing race conditions and ensuring data integrity in concurrent environments.
What are proper-lockfile's main functionalities?
Locking a file
This feature allows you to lock a file to prevent other processes from accessing it. The code sample demonstrates how to lock a file, perform some operations, and then release the lock.
const lockfile = require('proper-lockfile');
async function lockFile() {
try {
const release = await lockfile.lock('somefile');
console.log('File is locked');
// Do some work with the locked file
await release();
console.log('File is released');
} catch (err) {
console.error('Failed to lock file', err);
}
}
lockFile();
Checking if a file is locked
This feature allows you to check if a file is currently locked. The code sample demonstrates how to check the lock status of a file.
const lockfile = require('proper-lockfile');
async function checkLock() {
try {
const isLocked = await lockfile.check('somefile');
console.log(`File is ${isLocked ? 'locked' : 'not locked'}`);
} catch (err) {
console.error('Failed to check lock status', err);
}
}
checkLock();
Unlocking a file
This feature allows you to manually unlock a file. The code sample demonstrates how to unlock a file that was previously locked.
const lockfile = require('proper-lockfile');
async function unlockFile() {
try {
await lockfile.unlock('somefile');
console.log('File is unlocked');
} catch (err) {
console.error('Failed to unlock file', err);
}
}
unlockFile();
Other packages similar to proper-lockfile
lockfile
The lockfile package provides similar functionality for file locking. It is simpler but less feature-rich compared to proper-lockfile. It allows you to create, check, and remove locks on files.
async-lock
The async-lock package provides a general-purpose locking mechanism for asynchronous code. While it is not specifically designed for file locking, it can be used to manage access to resources in a concurrent environment.
rwlockfile
The rwlockfile package provides read-write locks for files. It allows multiple readers or a single writer to access a file, offering more granular control compared to proper-lockfile.
proper-lockfile
An inter-process and inter-machine lockfile utility that works on a local or network file system.
Installation
$ npm install proper-lockfile
Design
There are various ways to achieve file locking.
This library utilizes the mkdir
strategy which works atomically on any kind of file system, even network based ones.
The lockfile path is based on the file path you are trying to lock by suffixing it with .lock
.
When a lock is successfully acquired, the lockfile's mtime
(modified time) is periodically updated to prevent staleness. This allows to effectively check if a lock is stale by checking its mtime
against a stale threshold. If the update of the mtime fails several times, the lock might be compromised. The mtime
is supported in almost every filesystem
.
Comparison
This library is similar to lockfile but the latter has some drawbacks:
- It relies on
open
with O_EXCL
flag which has problems in network file systems. proper-lockfile
uses mkdir
which doesn't have this issue.
O_EXCL is broken on NFS file systems; programs which rely on it for performing locking tasks will contain a race condition.
-
The lockfile staleness check is done via ctime
(creation time) which is unsuitable for long running processes. proper-lockfile
constantly updates lockfiles mtime
to do proper staleness check.
-
It does not check if the lockfile was compromised which can lead to undesirable situations. proper-lockfile
checks the lockfile when updating the mtime
.
-
It has a default value of 0
for the stale option which isn't good because any crash or process kill that the package can't handle gracefully will leave the lock active forever.
Compromised
proper-lockfile
does not detect cases in which:
- A
lockfile
is manually removed and someone else acquires the lock right after - Different
stale
/update
values are being used for the same file, possibly causing two locks to be acquired on the same file
proper-lockfile
detects cases in which:
- Updates to the
lockfile
fail - Updates take longer than expected, possibly causing the lock to become stale for a certain amount of time
As you see, the first two are a consequence of bad usage. Technically, it was possible to detect the first two but it would introduce complexity and eventual race conditions.
Usage
.lock(file, [options])
Tries to acquire a lock on file
or rejects the promise on error.
If the lock succeeds, a release
function is provided that should be called when you want to release the lock. The release
function also rejects the promise on error (e.g. when the lock was already compromised).
Available options:
stale
: Duration in milliseconds in which the lock is considered stale, defaults to 10000
(minimum value is 5000
)update
: The interval in milliseconds in which the lockfile's mtime
will be updated, defaults to stale/2
(minimum value is 1000
, maximum value is stale/2
)retries
: The number of retries or a retry options object, defaults to 0
realpath
: Resolve symlinks using realpath, defaults to true
(note that if true
, the file
must exist previously)fs
: A custom fs to use, defaults to graceful-fs
onCompromised
: Called if the lock gets compromised, defaults to a function that simply throws the error which will probably cause the process to dielockfilePath
: Custom lockfile path. e.g.: If you want to lock a directory and create the lock file inside it, you can pass file
as <dir path>
and options.lockfilePath
as <dir path>/dir.lock
const lockfile = require('proper-lockfile');
lockfile.lock('some/file')
.then((release) => {
return release();
})
.catch((e) => {
console.error(e)
});
.unlock(file, [options])
Releases a previously acquired lock on file
or rejects the promise on error.
Whenever possible you should use the release
function instead (as exemplified above). Still there are cases in which it's hard to keep a reference to it around code. In those cases unlock()
might be handy.
Available options:
realpath
: Resolve symlinks using realpath, defaults to true
(note that if true
, the file
must exist previously)fs
: A custom fs to use, defaults to graceful-fs
lockfilePath
: Custom lockfile path. e.g.: If you want to lock a directory and create the lock file inside it, you can pass file
as <dir path>
and options.lockfilePath
as <dir path>/dir.lock
const lockfile = require('proper-lockfile');
lockfile.lock('some/file')
.then(() => {
return lockfile.unlock('some/file');
});
.check(file, [options])
Check if the file is locked and its lockfile is not stale, rejects the promise on error.
Available options:
stale
: Duration in milliseconds in which the lock is considered stale, defaults to 10000
(minimum value is 5000
)realpath
: Resolve symlinks using realpath, defaults to true
(note that if true
, the file
must exist previously)fs
: A custom fs to use, defaults to graceful-fs
lockfilePath
: Custom lockfile path. e.g.: If you want to lock a directory and create the lock file inside it, you can pass file
as <dir path>
and options.lockfilePath
as <dir path>/dir.lock
const lockfile = require('proper-lockfile');
lockfile.check('some/file')
.then((isLocked) => {
});
.lockSync(file, [options])
Sync version of .lock()
.
Returns the release
function or throws on error.
.unlockSync(file, [options])
Sync version of .unlock()
.
Throws on error.
.checkSync(file, [options])
Sync version of .check()
.
Returns a boolean or throws on error.
Graceful exit
proper-lockfile
automatically removes locks if the process exits, except if the process is killed with SIGKILL or it crashes due to a VM fatal error (e.g.: out of memory).
Tests
$ npm test
$ npm test -- --watch
during development
The test suite is very extensive. There's even a stress test to guarantee exclusiveness of locks.
License
Released under the MIT License.